fix(security): do not HTML-purify Turnstile tokens - #29

Thanks for this — the diagnosis is right and the test is a good addition.

I confirmed the bug independently: passing a token through the purifier turns & into &, and a < truncates it, so a token containing either fails validation. Plain base64url tokens come through untouched, which is presumably why this went unnoticed for so long. Your test passes here too (7/7).

One request before merge, on the shape rather than the substance.

Core already has an idiom for reading a value without any transformation: Params::getParamString($name, false, false). That is what the installer uses for passwords, which have the same "must arrive byte-for-byte" requirement — see install-functions.php lines 371, 393 and 512. osc_posted_captcha_token() adds a new permanent public global that reads $_POST directly and bypasses Params entirely, and once a global helper ships we are committed to keeping it for plugin compatibility.

The one thing your helper genuinely adds over the existing idiom is POST-only enforcement, and that is worth keeping. Could it become a small private method on the captcha class, or a Params call plus an explicit request-method check at the call site, rather than a new global?

Separately, and not something you introduced — the guard immediately above is broken:

if ($gReCaptchaResponse !== '' || $gReCaptchaResponse !== false || $gReCaptchaResponse !== 0)

Those are ORed, so the condition is always true regardless of the value (php -r returns bool(true) for an empty string). The empty-token check has never actually fired. Since you are already in this function, folding that into the same PR would be welcome — but happy for it to be a follow-up if you would rather keep this one focused.

Also note the branch is currently conflicting with develop.

Thanks — I took the shape change.

The extra global is gone. Call sites now use Params::getParamString($name, false, false) (same as installer passwords) plus an explicit POST method check. The always-true empty-token guard is === '' and returns false. Tests pin the unpurified Params path and that GET is rejected.

Still needs a merge of current develop for the CHANGELOG conflict; I can do that on the next push if you want it from this side.